Many organizations are becoming more involved in conducting business electronically (so called e-business), over the Internet, or on other computer networks. E-business calls for specialized applications software such as Electronic Bill Presentment and Payment (EBPP) and Electronic Statement Presentment applications. To implement such applications, traditional paper documents have to be converted to electronic form to be processed electronically and exchanged over the Internet, or otherwise, with customers, suppliers, or others. The paper documents will typically be re-formatted to be presented electronically using Hypertext Markup Language (HTML) Web pages, e-mail messages, Extensible Markup Language (XML) messages, or other electronic formats suitable for electronic exchange, processing, display and/or printing.
Billers who provide their customers with the option of viewing and paying their bills over the Internet have varying requirements for business content to present. In addition to varying content, different billers will want the customer interface and presentation of the billing information to have a particular “look-and-feel.”
Instead of programming their own EBPP system from scratch, billers have the option of purchasing or outsourcing a pre-made EBPP system from a vendor. The biller may also hire a third party electronic billing service to provide the desired EBPP services to the biller's customers. In any of these situations, a pre-made EBPP system must be customized to meet the particular business and presentation requirements of the biller. Accordingly, a vendor who provides an EBPP solution to multiple billers needs to consider the extent to which its system can be customized, and the ease with which customization can be achieved.
FIG. 1 depicts a prior art EBPP system. In the prior art system, for one or more billers, EBPP computer system 10 controls the presentment of billing service web pages 40 over the Internet 2 to customer 1. Billing information is gathered by EBPP computer system 10 from the biller's legacy computer systems 20. Typically, billing data will be parsed by EBPP system 10 from a print stream generated by the legacy system 20, the legacy print stream being originally intended for printing conventional hard-copy bills. A preferred method for parsing billing data from the legacy print stream is described in co-pending patent application Ser. No. 09/502,314, titled Data Parsing System for Use in Electronic Commerce, filed Feb. 11, 2000, which is hereby incorporated by reference into this application.
In addition to communication via web pages 40 generated during a session, EBPP computer system 10 includes the capability of sending and receiving e-mail messages 50 to and from the user 1. Typically, system 10 will generate a message to user 1 upon the occurrence of a predetermined event. An example of such an event is a new billing statement becoming available, or the approach of a due date for an unpaid bill. EBPP system 10 is also capable of communicating with a bank or ACH network 30 to process bill payment activities.
System 10 also includes a data repository 11 in which billing data for use with system 10 may be stored in a variety of formats. Data in the repository can be organized in a database, such as the kind available from Oracle or DB2. Statement data archives may also be stored in a compressed XML format. XML is a format that allows users to define data tags for the information being stored.
The EBPP computer system 10 itself is typically comprised of standard computer hardware capable of processing and storing high volumes of data, preferably utilizing a J2EE platform. EBPP system 10 is also capable Internet and network communications. The prior art EBPP computer system 10 includes a software architecture within an application server 12 for generating and handling electronic billing functions. At a fundamental level, the software architecture of the prior art system 10 is split into two conceptual components, the front-end presentation logic 13 and the back-end servicing logic 14. The split between front-end and back-end logic 13 and 14 serves to reduce the amount of recoding necessary for the system to be customized for different billers.
The front-end presentation logic 13 is the portion of the software that is the primary Internet interface for generating web page presentations. As such, the front end presentation logic 13 includes code that is custom written to meet the specific business and presentation needs of the biller. Functionalities that might be included in front-end logic 13 are enrollment, presentation, payment instructions, and reporting.
Typically, front-end logic 13 is comprised of Java Server Pages (JSP's) that control the presentation of billing information in the form of web pages. The front-end logic JSP's also receive and respond to inputs as the customer makes requests for various services to be provided. The JSP's can be recoded to accommodate different look-and-feel and business requirements of different billers. Within the JSP's, front-end logic 13 can also utilize Enterprise Java Beans'(EJB's) that comprise objects for performing specific tasks.
The back-end services logic 14 comprises the software for functions that typically do not need to be customized for particular billers. Preferably, very little of the back-end services must be customized for a particular biller's needs. For example, back-end logic may include the software for extracting the billing data from the biller legacy billing computers 20. Similarly, logic for handling of payments with the bank or ACH network 30 and systems for generating and, receiving e-mail messages will be handled in the back-end services logic 14.
As a result of the distinction between the front-end and back-end logic 13 and 14, re-coding of software to provide customization for different billers is somewhat reduced. However, a significant amount of presentation logic and some business logic must always re-written to meet a particular biller's needs. The re-coding required for customization can require a high degree of programming skill and can add expense to implementation of a biller's on-line presence. The requirement for re-writing code introduce a risk that changes to the way that a web page looks may in fact introduce a problem that could cause the content of the information being displayed to be incorrect. Another problem with this prior art system is that after a system is customized, it may be difficult to provide upgrades and future releases of the software. In order to be sure that new releases work properly, substantial efforts would be necessary to retrofit the new release with the code changes that were made for the particular customer.
As shown in FIG. 2, the prior art EBPP system 10 also included a data transfer interface 15 between the front and/or back-end logic, 13 and 14, and the data repository 140. The interface 15 includes logic for retrieving data from the data repository 140 based on requests generated by the system 10. Interface 15 is typically comprised of SQL scripts and Java code for specialized data handling functions. Since a common type of data repository is a relational database, SQL commands are usually suitable for retrieving data from repository 140. Thus, in the prior art EBPP system 10 the front and back-end logic modules 13 and 14 typically include SQL specific commands in requests passed to the data transfer interface 15. These commands are utilized by the interface 15 to retrieve the appropriate information from the data repository 140.
As with the front-end presentation logic 13 and the back-end services logic 14 discussed above, problems can arise in providing biller-centric customization to the data transfer interface 15. In implementing biller specific data retrieval needs, the data transfer interface must be reprogrammed with particular care to keep the SQL scripts and the Java code in synch. An example of a potential error occurs when a programmer might add Java code to handle an added customized field in a table, but would forget to add the field in the SQL “create table” script.
The labor and potential for errors are also a concern when billers require customization that includes access to data from their own existing, non-relational databases. For instance, user information might be stored in an LDAP repository. It may be difficult to adapt the prior art system to this sort of situation, especially since SQL code fragments existed in the requests generated by the front and back-end logic 13 and 14. As a result, in order to support a non-SQL-based data source, changes need in the front-end logic 13 and possibly the back-end logic 14. Such re-coding of logic is burdensome and error prone.